1. Field
The present inventive concept pertains to a system and method to command physical hardware of a computer system. The present inventive concept more particularly concerns an improved system and method to bypass a potentially compromised chain of trust internal to a normal or standard device driver input/out (“I/O”) stack, and utilize the crash dump driver stack to control a physical hardware device.
2. Discussion of Related Art
Information security forensic investigators seek to obtain uncontaminated evidence or data from compromised computing devices. Investigators use forensic tools that rely on facilities provided by operating systems to acquire the evidence. At the lowest level, such facilities may include the kernel, the I/O subsystem, and various device drivers for interacting with disk drives, network cards and other peripheral hardware, which are implemented in the operating system (“OS”).
A driver translates information from a generic interface to a more specific form suited for hardware, firmware, or software functionalities. Drivers and the OS allow applications to operate without concern for the details of underlying hardware. For example, when an application writes a file to disk, it does so without regard to the underlying technologies, that is, the OS and drivers provide an abstract representation of a mass storage device that obscures the low-level differences between various types of mass storage technology. Abstraction is also used within the OS, for example, when an application calls upon “save data” functionality provided by the OS. Save data functionality will be accessed through drivers provided by the device manufacturer.
Using an example of a mass storage device, the use of abstraction means an application does not need to know if the mass storage device has a magnetic read-write head or uses flash memory chips. In general, an OS has a published specification documenting how it will communicate with different classes of physical hardware devices: mass storage devices, routers, printers, and other similar devices. Manufacturers who want their peripheral devices to work with the OS are responsible for providing a low-level driver for the device. The key advantage of the device driver structure of communication and control is that high-level software components can treat all devices of a given driver class as a single, generic device.
Stacks are chains of software and/or hardware computer components that translate an application request such as “save data” to physical actions such as writing data to a disk platter or memory chip. Device driver stacks may comprise several layers, from low-level hardware-specific drivers provided by device manufacturers, to high-level drivers that translate information for communication with a plurality of disparate components. Implicit in the use of stacks is a chain of trust, where each layer of the stack trusts that the layers above and below it will conform to certain standards and expectations and that data will not be maliciously modified within any layer of the stack.
In FIG. 1, an example of a stack is illustrated in communication with an application 108, and includes an application program interface 110 and a kernel space 104 which includes a number of drivers such as the miniport driver 120, port driver 122, and bus driver 124. In this example, the application 108 in user space 102 uses facilities provided in the kernel space 104 to communicate or control a physical hardware device 128, such as a mass storage device, in hardware layer 106.
Many investigatory and forensic tools used by various investigators rely on standard OS components such as those illustrated in FIG. 1 to perform data collection and analysis. However, well-crafted malicious software such as viruses or malware in a compromised computing device can subvert these components by providing or causing the return of false and misleading data, thereby thwarting the efforts of the investigator. For example, such malicious software can be embedded in a device driver stack to allow an attacker to modify data streams and to inject false data, conceal evidence of system compromises, receive command control instructions, and maintain control of the host computing device.
Malicious software that modifies the Master Boot Record (“MBR”), which is software that enables the computing device to boot from a mass storage device, will often inject code that intercepts requests to read data from the MBR. When an investigator tries to examine the MBR through OS components such as the device's driver stack, the malicious software will often substitute innocuous MBR data in place of obviously-compromised data in an attempt to fool the investigator. “Whitewashing” of the Master Boot Record, for example, can prevent conventional investigation tools from detecting that the MBR is compromised. “Whitewashing,” as used herein, means to remove data indicative of a compromise, for instance, data that would allow an investigator to believe a computing device may be compromised by malicious software or the like.
An example of a compromised device driver stack 111 is illustrated in FIG. 2. In this example, a mass storage device's driver stack is shown in the kernel space 104, and a legitimately installed anti-virus toolkit 130 has injected itself in the device driver stack 111, as has a malicious rootkit 132. The anti-virus toolkit 130 can monitor the data stream, analyzing it for signs of compromise, but the rootkit 132 will also monitor the data stream with the goal of stealthily modifying the data for the benefit of the attacker. If, in this example, the rootkit 132 is modifying the data stream before the anti-virus toolkit 130 has analyzed the data for signs of compromise, the anti-virus toolkit 130 may not be able to detect the rootkit 132.
Numerous solutions have been proposed to remedy this contamination problem. Anti-virus and Host Intrusion Prevention System (“HIPS”) vendors attempt to uninstall the rootkit 132 dynamically or put measures in place to prevent the rootkit 132 from installing at all. These approaches become a classic cat-and-mouse game, as the rootkit 132 author simply installs at some other junction in the normal I/O path or subverts the prevention measure itself. Additionally, it is often the case that “whoever is there first” wins this battle, because all software that operates at the kernel space 104 has equal privileges. Some companies have put measures in place to protect critical components in chains of trust such as the device driver stack 111, but the rootkit 132 authors continue to circumvent existing measures and infect computing devices.
Thus, information security forensic investigators face the challenge of commanding physical hardware devices, including to obtain data from such devices, using OS components that may return compromised or otherwise untruthful data.